Issue & Reproduction Steps

• After upgrading to Axios 1.x, the screen-builder HTTP cache integration broke: the browser threw Uncaught (in promise) TypeError: t is not a function inside the axios dispatch path (stack pointed at bundled cacheAdapterEnhancer / app.js).
• Root cause: @processmaker/screen-builder’s initializeScreenCache() wraps apiClient.defaults.adapter with axios-extensions’ cacheAdapterEnhancer. In Axios 1.x, defaults.adapter is often a list of adapter names (e.g. ['xhr','http','fetch']), not a callable adapter. The enhancer must receive the resolved adapter from apiClient.getAdapter(...).
• Build: Importing axios-extensions triggered Module not found: Package path ./lib/helpers/buildURL is not exported because Axios 1 no longer exports the old deep path axios/lib/helpers/buildURL.
• Runtime (after build fix): LRUCache is not a constructor because the app resolved hoisted lru-cache@5 (default export only) while the code used a named { LRUCache } import (v10 style).

Solution

• Added resources/js/common/attachScreenCacheAdapter.js: resolves the real HTTP adapter with apiClient.getAdapter(apiClient.defaults.adapter) when defaults.adapter is not a function, then applies cacheAdapterEnhancer with the same options as screen-builder (cache flag, LRU defaults, screen config).
• resources/js/bootstrap.js: stopped calling initializeScreenCache from screen-builder; calls attachScreenCacheAdapter(apiClient, window.ProcessMaker.screen) after ProcessMaker.screen is defined.
• resources/js/next/screenBuilder.js: same behavior for the dynamic screen-builder path, passing the local screen object.
• webpack.mix.js: Resolve.alias for axios/lib/helpers/buildURL → node_modules/axios/lib/helpers/buildURL.js so axios-extensions builds against Axios 1 exports.

How to Test

1. npm ci (or npm install), then npm run development — confirm webpack completes with no axios/lib/helpers/buildURL error.
2. Load the main app (layout using bootstrap.js): confirm no t is not a function and no LRUCache is not a constructor in the console on load and on normal navigation/API use.
3. Toggle screen-cache-enabled (and timeout) via admin/meta as you normally do: confirm GETs still behave correctly with cache on/off (no adapter errors).
4. If you use the next screen-builder loader path, hit a page that runs resources/js/next/screenBuilder.js and repeat smoke checks.

Related Tickets & Packages

• Packages: @processmaker/screen-builder (upstream still exports initializeScreenCache with Axios 0.x assumptions), axios, axios-extensions, lru-cache.
• Tickets: Link your FOUR-28803 ticket here (e.g. “Axios 1.x: screen cache adapter / frontend build”).

Code Review Checklist

• I have pulled this code locally and tested it on my instance, along with any associated packages.
• This code adheres to ProcessMaker Coding Guidelines.
• This code includes a unit test or an E2E test that tests its functionality, or is covered by an existing test.
• This solution fixes the bug reported in the original ticket.
• This solution does not alter the expected output of a component in a way that would break existing Processes.
• This solution does not implement any breaking changes that would invalidate documentation or cause existing Processes to fail.
• This solution has been tested with enterprise packages that rely on its functionality and does not introduce bugs in those packages.
• This code does not duplicate functionality that already exists in the framework or in ProcessMaker.
• This ticket conforms to the PRD associated with this part of ProcessMaker.